Repository navigation
Fix bare requirements wheel paths not contesting VEX (#1587) - #1599
Mikola Lysenko (mikolalysenko) merged 5 commits into
Conversation
Assisted-by: Claude Code:claude-opus-5-5
A requirements.txt line such as `wheels/six-1.16.0-py3-none-any.whl`, `six-1.16.0-py3-none-any.whl` or `dist/six-1.16.0.tar.gz` is installed by pip as a local, unpatched artifact. VEX discovery only treated a line as a path when it began with `.`, `/` or another non-alphanumeric character, so these spellings gave no evidence and `vex` attested not_affected for a Socket wiring of the same release in Pipfile.lock. Read a line as a path the way pip does: it holds a path separator, starts with something other than a letter or digit, or names an archive (`.whl`, `.tar.gz`, `.zip`, ...). `name@<location>` stays a PEP 508 direct reference, as in pip. Fixes #1587 Assisted-by: Claude Code:claude-opus-5-5
Move the "pip installs this as a local artifact" rule into utils::requirements beside the shared requirements grammar, and follow pip more closely: - `six@https://...` (no spaces) is a PEP 508 reference to six, not a bare url, as pip reads it. - A path's `[extras]` are cut before its filename is read, so `wheels/six-1.16.0-...whl[socks]` also contests the wiring. - The archive test splits `.tar.<ext>` the way pip's splitext does. Refs #1587 Assisted-by: Claude Code:claude-opus-5-5
|
BugBot review Generated by Claude Code |
|
Labeled Ready for review at head
Generated by Claude Code |
…s-bare-path-contest
Port of #1639. setup-uv installs the latest uv when no version is given, and uv 0.13.2+ refuses the `environments = []` pylock that Pipenv 2026.8.0 writes ("The target environment is not supported by the lockfile"). That broke the e2e_vex_build pipenv leg on main and in the merge queue, unrelated to this change. Pin uv 0.13.1, the last version those legs passed on. This no-ops once #1639 lands. Assisted-by: Claude Code:claude-opus-5-5
|
[agent] Dequeued on I ported #1639's pin (uv 0.13.1 in Generated by Claude Code |
|
Wenxin Jiang (@Wenxin-Jiang) this changed after your approval (on Besides merges from main, the only new commit is 29877b3: the CI-only uv pin from #1639, byte-for-byte the same 12 added lines ( If that's fine with you, re-approving Generated by Claude Code |
|
bugbot run Generated by Claude Code |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 29877b3. Configure here.
|
Ready for review re-confirmed at the new head (burn-down agent).
Generated by Claude Code |
LLM Description written by Claude Code:claude-opus-5-5
Fixes #1587
Summary
pip installs a requirements.txt line such as
wheels/six-1.16.0-py3-none-any.whl,six-1.16.0-py3-none-any.whlordist/six-1.16.0.tar.gzas a local, unpatched artifact. Before this fix,vexignored those lines and attestednot_affectedfor a Socket wiring of the same release in Pipfile.lock. Only the./wheels/…spelling was withheld (#1562). These spellings now contest the wiring the same way, sovexwithholds the statement withpatched_ref_unattributable.Root cause
requirement_location(crates/socket-patch-core/src/vex/discover/pypi_other.rs) read a line as a path only when its first character wasn't a letter or digit. pip's rule (_looks_like_path/_get_url_from_path) is different: a token is a path when it holds a path separator, starts with., or names an archive file.Changes
utils::requirements, the shared requirements grammar, gets pip's rule aspip_reads_as_path, withis_archive_file(pip'sARCHIVE_EXTENSIONS, and itssplitexthandling of.tar.<ext>),names_before_atandstrip_path_extras.requirement_locationuses these helpers and now also follows pip on two more points:six@https://…orsix@wheels/…whlis a PEP 508 reference tosix. Before, the url form was read as a bare url and lost its declared name.[extras]are cut before its filename is read, sowheels/six-…whl[socks]also contests.Tests (red → green)
wheels/…whl,…whl,dist/…tar.gz,wheels\…whl, path with a;marker, vendored Pipfile.lock wiringvex::discover::pypi_other::tests::issue_1549_non_socket_direct_references_contest_wiring(new cases)vex::discover::pypi_other::tests::issue_1587_requirement_location_reads_paths_as_pip_doesleft: None)utils::requirements::tests::pip_reads_as_path_follows_pipvex, hosted and vendored wiringe2e_vex_lockfile pipenv::requirements_direct_reference_contests_the_lock_wiring(the issue's three spellings)vexexit 0)The red runs used main's
pypi_other.rswith the new e2e cases in place.Local runs:
cargo fmt --all -- --check: cleancargo clippy --workspace --all-features -- -D warnings: cleancargo test -p socket-patch-core --lib: 6536 passed, 4 failed. The 4 are chmod-based tests that can't fail under uid 0 in this sandbox:relax_loop_must_not_traverse_symlinked_root,an_unremovable_hidden_lock_keeps_every_store_entry, and the poetry and requirements write-failure tests. Other agent PRs report the same 4 on main.e2e_vex_lockfile: 350 passede2e_vex_redirect(53),e2e_vex_vendor(52),in_process_redirect_pipenv(11),in_process_vendor_pypi_takeover(6),scan_requirements_lock_only(10) andscan_vendor_requirements_unwired(4): all passCI and Bugbot
Merge queue (2026-10-20): dequeued on the pipenv pylock leg, a main-wide break from uv 0.13.2+ (also fails main nightly, #1605, #1614). Ported #1639's uv 0.13.1 pin in 29877b3 after merging main; CI green there, pipenv leg included.
CI on 3a4de37:
ci-okgreen, no failed checks. Bugbot reviewed 3a4de37 and found no issues./code-review high
Fixed in 3a4de37:
six@https://…lost its declared name.[extras]on a path hid its filename..tar.<ext>the way pip does.Not changed:
.tar,.tbz,.txz,.tlz,.tar.lz,.tar.lzma) are now read as paths. The release can't be read from those filenames, though, so they still give no evidence, as before this PR. Real sdists use.tar.gzor.zip(PEP 625 requires.tar.gz). Widening the filename reader would also change the hosted rewriter and the lock inventory.requirement_namestill reads a bare path line as a name (wheels). These writers don't attest anything. Whether they should treat such a line as an install source of the package is a separate change, left as a follow-up.https://claude.ai/code/session_01JM7idHTBGCQp9fzoGJviT3
Note
Medium Risk
Changes VEX contesting logic for requirements.txt parsing, which affects attestation outcomes when alternate install sources coexist with lock wiring; scope is localized to PyPI/VEX discovery with broad test coverage.
Overview
Fixes #1587: VEX discovery now treats
requirements.txtlines that pip installs as local artifacts—e.g.wheels/six-….whl, bare wheel filenames, anddist/….tar.gz—as install sources that contest Socket wiring inPipfile.lock, instead of only recognizing./wheels/….The shared requirements grammar gains pip-aligned helpers (
pip_reads_as_path,names_before_at,strip_path_extras,is_archive_file), andrequirement_locationuses them so no-spacename@url/name@pathPEP 508 references keep a declared name and path[extras]are stripped before reading the location.CI pins uv 0.13.1 in
ci.ymlandpipenv-compatibility.ymlbecause uv 0.13.2+ rejects Pipenv’s empty-environments pylock used in PEP 751 test legs.Unit, discovery, and Pipenv e2e tests cover the new spellings and parser behavior.
Reviewed by Cursor Bugbot for commit 29877b3. Configure here.
Generated by Claude Code